Document processing system with improved image quality assurance

ABSTRACT

A document processing system comprising an image capture subsystem for capturing selected image metrics and at least one image rendition from a plurality of documents and for determining if at least one of the selected image metrics for any of the at least one image rendition does not successfully compare against preselected image quality metric threshold values. An image quality flag is generated for any of the at least one image rendition if it does not successfully compare, and a record entry for each imaged document having at least one flagged image rendition is created in an image quality flag file. An image index file for individually accessing the image renditions is modified to include a reference to the corresponding image quality flag file record entry The document processing system may optionally compare selected document metrics against preselected document metrics in a similar manner. Image defects in the plurality of documents can be identified by examining the record entries in the image quality flag file.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to:

U.S. patent application Ser. No. <TBD>, entitled “Image QualityAssurance Systems and Methodologies for Improving the Identification ofand Access Speed to Image Quality Suspects in Documents” (Klein et al.),filed concomitantly herewith;

U.S. patent application Ser. No. <TBD>, entitled “Image File Arrangementfor Use with an Improved Image Quality Assurance System,” (Klein etal.), filed concomitantly herewith; and,

U.S. patent application Ser. No. <TBD>, entitled “Image QualityAssurance Methodologies in a Post-Image Capture Document ProcessingEnvironment” (Klein et al.), filed concomitantly herewith;

all of which are incorporated by reference herein and assigned to theassignee of the present application.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to imaging, and more specifically, to adocument processing system with an improved image quality assurancemethodology.

2. Background Art

On Jun. 6, 2003, the United States House of Representatives passed “TheCheck Clearing for the 21^(st) Century Act.” Following the passage ofthe House Bill, the United States Senate enacted on Jun. 27, 2003, S.1334, “The Check Truncation Act of 2003.” Both of these legislations arereferred to informally as “Check 21” legislation. The law aims toimprove the check and remittance payment systems by allowing banks,financial institutions, and remittance payment processors (e.g., utilityand insurance companies) to exchange checks electronically instead ofthe current paper-based exchange. President George W. Bush signed theCheck 21 legislation into law on Oct. 28, 2003, and when the law goesinto effect on Oct. 28, 2004, a printed image of a check or remittanceprocessing stub will have the same legal standing as its original papercounterpart.

Under current law, banking institutions must physically present andreturn the original paper checks received from customers and otheraccountholders. Within recent past years, banks, financial institutions,and remittance payment processors (e.g., utility and insurancecompanies) have been moving away from paper-based financial documentprocessing environments toward image-based processing environments whereimages of checks and remittance processing stubs are used to performdata entry, correction and balancing operations. The adoption of suchimage-based document processing has yielded improvements in processingthroughput and reduced labor costs.

The Check 21 law allows banks to voluntarily exchange electronic imagesover networks, legally acknowledging an electronic financial document asthe legal equivalent of a paper financial document. In this checktruncation environment, only images of the checks would beelectronically transmitted between financial institutions and the paperdocuments would be held or destroyed by the bank of first deposit.Financial institutions desiring to continue processing paper couldreceive a substitute check, i.e., a paper reproduction created from anelectronic image of the original check, for clearing and settlement andultimate return to the accountholder. This substitute check would havethe legal equivalence of the original paper check.

It is expected that the introduction of this law will allow a financialinstitution's customers to benefit from new products and services, suchas online access to their check images. In addition, improved service isanticipated in view of the significantly reduced response time requiredfor account information about checks, and avoidance of negative economicimpacts is improved in view of the significantly reduced dependence onair transportation networks, which are vulnerable to expected orunexpected disruptions (such as strikes, weather, natural disaster,terrorist attacks or other types of crises). There is a 12-monthimplementation period, which began on Oct. 28, 2003, during which bankscan roll out imaging technology and set up electronic exchanges withpartner institutions.

In view of these changes, and in order to attempt to achieve anacceptable and accepted standard among the aforementioned institutions,the Accredited Standards Committee (ASC) for Financial Services (X9B)has drafted a proposed financial image interchange standard(Specifications for Electronic Exchange of Check and Image Data, DSTUX9.37-2003, currently under revision, hereinafter referred to as “theX9.37 standard”) to support the exchange of check/document imagerybetween financial institutions. Although this standard has not beenfinalized or officially adopted, it has been provisionally selected bythe Federal Reserve, the central bank of the United States.

However, one issue that arises with check truncation is the newrequirement that some level of image quality assurance (IQA) beperformed on the check images prior to image interchange between twofinancial institutions. The goal of IQA would be to provide some levelof assurance that the check image renditions being created by the“sending” financial institution are of suitable quality and legibilityto support follow-on financial document processing operations by the“receiving” financial institution.

In addressing this issue, the X9.37 standard has included thespecification of a “minimum set” of image quality assurance (IQA)“flags” for each image being transmitted or exchanged. The purpose ofthese IQA flags is to identify questionable, or suspect, document imagesthat might exhibit one or more image quality defects. Currently, theworking definition of an “image quality defect” is some defect in thedigital image rendition of the check that prohibits its use as asubstitute for the original paper document during the payment process.It will be appreciated that such use prohibition may be definedaccording to the nature of subsequent processing that is to occur. Forexample, such prohibition might occur if the image does not meet theCheck 21 requirement that the substitute check “accurately representsall of the information on the front and back of the original check as ofthe time the original check was truncated,” or as indicated, infra, ifthe defect “can fatally compromise recognition of printed or writteninformation by either intelligent character recognition (ICR) systems orby a data entry operator.”

Typical image quality defects may include such items as: 1) Images ofchecks with folded corners (obscuring some portion of the documentwriting), 2) images of documents that are excessively skewed, perhapscausing the top portion of the image to be missing (outside the field ofview of the image camera), 3) images that exhibit poor contrast orexcessive brightness (reducing the legibility of the document), 4)images of two documents that are overlapped causing one document to bepartially obscured, and 5) document images whose compressed image filesizes (in kilobytes) are too small or too large. In many cases, thesedefects in document image quality, albeit occasional, can fatallycompromise recognition of printed or written information by eitherintelligent character recognition (ICR) systems or by a data entryoperator.

It is therefore expected that those equipment vendors who supplyimage-enabled document processing platforms, as well as those whoprovide image-enabled document processing applications, will need toprovide methods and systems to automatically perform image qualityassurance for all images generated or created by their documentprocessing platform/solution. It is envisioned that each document imagewill be tested for the presence of one or more image “defects”, andthese defects will be recorded and then stored with the image file/dataprior to image interchange between the two banks.

In the past, companies have performed a variety of methods forautomatically detecting image quality defects associated with thedocument image capture process. The automatic detection of image qualitydefects generally relies on defining a set of image metrics that can beused to infer probable image quality problems in a document image.Typical image metrics to assess image quality may include: imagedimensional data (e.g., image height and width), compressed image packetsize, image gray level histograms, image skew angle, hardware/softwarefeed check errors, and other transport status/error detectioninformation.

Recently, some companies have demonstrated a variety of methods forautomatically detecting image quality defects associated with thedocument image capture process, and some advances have been made withregard to the automatic detection of image quality defects in documentimaging platforms. However, the known image quality flag implementationscurrently being proposed by the vendors and the interchange standardscommittees (e.g., IBM and X9.37) involve the appending or embedding ofimage quality “lag” bits or data records directly into the existingcheck image file formats. Examples of the image quality flags set forthin the X9.37 standard are set forth in Appendix A. Although thismethodology provides a vehicle for storing image quality flags for eachdocument image, it does not provide a method for image-based documentprocessing applications (e.g., check image processing applications) toquickly identify which images are suspected of containing one or moreimage quality defects.

Using such a method to store image quality flag data for each checkimage requires that a software application sequentially search/examinethe image flag data records stored in each image file for the presenceof one or more image quality flags following image capture. FIG. 1illustrates such a typical IQA implementation scheme. As seen therein,as each document is imaged during the image capture process 100, one ormore image rendition files are created at 102 for the front and rear ofeach document (i.e., a front image file (FIM) 104, a rear image file(RIM) 106, a second front image file (FI2) 108, a second rear image file(RI2) 110). Additionally, an image index file (IDX) 112 is created sothat any of the aforementioned individual image files may be accessed byextracting the data stored in the IDX file 112. Finally, an end-of-file(EOF) semaphore file 114 is created to signal the completion of imagecapture processing for a batch of documents.

At least one image measure metric is determined at IQA metric generationprocess 118. Image measure metrics may be related to either the documentprocessing and/or imaging hardware or the imaging software. Examples ofhardware-related image measure metrics might include document imageheight and length, document skew, etc. Software-related image measuremetrics might include compressed image packet size and front imagedimensions compared to rear image dimensions.

Image quality flag (IQF) parameters such as discussed above and as setforth in Appendix A, and predetermined thresholds based on theseparameters (120), are applied to image measures determined by the IQAmetric generation process 118 at 122 in order to determine whether ornot IQA flags (124) are to be set. If IQA flags are to be set, then theyare embedded directly in the appropriate image files (i.e., FIM, RIM,FI2, RI2) at 126.

While this methodology may be sufficient for a small number of checks,it is not a particularly efficient method for use with large numbers ofchecks, particularly in view of the fact that the vast majority of checkimages do not have any quality defects present. As a result, thismethodology results in the wasting of a large amount of applicationprocessing time examining image quality flag data where no defects arepresent. Furthermore, for those check image-processing platforms capableof generating multiple image renditions, e.g., black/white, full grayscale, full resolution, for the front and rear of each check document,the search for imagery containing image quality defects becomes evenmore complex and time consuming.

Therefore it would be desirable to provide for the realization ofautomated IQA on image platforms with improved access speed to imagequality suspects, and particularly those implementing the X9.37 standardand its progeny.

SUMMARY OF THE INVENTION

It is, therefore, an object of the present invention to provide animproved document processing system.

It is another object of the present invention to provide improved imagequality assurance systems and methodologies in a document processingsystem.

It is yet another object of the present invention to improve theidentification of, and speed of access to image quality suspects in aplurality of imaged documents in a document processing system

It is still another object of the present invention to improve theidentification of, and speed of access to image quality suspects indocuments that are imaged in a document processing system having animage platform that is compliant with the X9.37 financial imageinterchange standard and its progeny.

In a first aspect of the invention a document processing system isprovided that includes a document transport for moving a plurality ofdocuments and at least one computer running system software thatinterfaces with the document transport to provide document control. Thedocument processing system further comprises: an image capture subsystemconnected to the document transport for capturing selected image metricsand at least one image rendition from the plurality of documents as theyare moved by the document transport. The image capture subsystemdetermines if at least one of the selected image metrics for any of theat least one image rendition does not successfully compare againstpreselected image quality metric threshold values and generates an imagequality flag for any of the at least one image rendition if it does notsuccessfully compare. The image capture subsystem creates in an imagequality flag file, a record entry for each imaged document having atleast one flagged image rendition, each record entry includinginformation about the at least one flagged image rendition for thatimaged document, whereby image defects in the plurality of documents canbe identified by examining the record entries in the image quality flagfile.

In a second aspect of the present invention, the document processingsystem comprises track hardware which provides selected document metricsfrom a plurality of documents as they are moved by the documenttransport. The image capture subsystem determines if at least one of theselected document metrics for any of the documents does not successfullycompare against preselected document metric threshold values, generatesan image quality flag for any of documents if it does not successfullycompare, and creates in the image quality flag file, a record entry foreach imaged document having at least one flagged document metric. Eachrecord entry includes information about the at least one flaggeddocument metric for that imaged document.

In a third aspect of the invention, the selected document metrics mayinclude information about the type and information about the physicaldimensions of each of the plurality of imaged documents. Such selectedmetrics may include a beam-of-light (BOL) “late” signal, a documentspacing error signal and/or a double document signal.

In a fourth aspect of the present invention, at least one imagerendition is captured and then stored according to type of imagerendition. An image index file including a document record entry foreach imaged document is created, the image index file for individuallyaccessing any of the stored image rendition files and for indexing intoany of the record entries in the image quality flag file. For each ofthe plurality of imaged documents, the image index file document recordentry is modified to include a global image quality flag indicating thatthe imaged document has been examined for image defects.

In a fifth aspect of the present invention, for each of the plurality ofimaged documents having at least one flagged image rendition, the imageindex file document record entry includes a reference to the imagequality flag file record entry for the corresponding imaged document anda global image quality flag for that image index file document recordentry is set, the global image quality flag indicating that the imageddocument has been examined for image defects and at least one defect hasbeen found.

Still other objects, features and advantages of the present inventionwill become readily apparent to those skilled in the art from thefollowing detailed description, wherein there is shown and describedonly the preferred embodiment of the invention, simply by way ofillustration of the best mode contemplated for carrying out theinvention. As will be realized, the invention is capable of other anddifferent embodiments, and its several details are capable ofmodifications in various obvious respects, all without departing fromthe invention. Accordingly, the drawings and description are to beregarded as illustrative in nature, and not as restrictive, and what isintended to be protected by Letters Patent is set forth in the appendedclaims. The present invention will become apparent when taken inconjunction with the following description and attached drawings,wherein like characters indicate like parts, and which drawings form apart of this application.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a functional block diagram of a prior art imagecapture system with known image quality assurance (IQA);

FIG. 2 illustrates a functional block diagram of an image capture systemwith image quality assurance (IQA) according to one embodiment of thepresent invention;

FIG. 3 illustrates a preferred embodiment of the file structure of animage quality file (IQF) for use with the image capture system withimage quality assurance (IQA) of FIG. 2 and the present invention and amodified IDX record structure for indexing to selected records in theimage quality file (IQF) file;

FIG. 4 illustrates a preferred embodiment of the file structure of theheader record of the image quality file (IQF) file of FIG. 3;

FIG. 5 illustrates a preferred embodiment of the structure of the imagequality metric thresholds in the header record of FIG. 4;

FIG. 6 illustrates a preferred embodiment of the structure of the imagequality records of the image quality file (IQF) file of FIG. 3;

FIG. 7 illustrates a preferred embodiment of the structure of the imagequality conditions of the image quality records of FIG. 6;

FIG. 8 illustrates an implementation of the image capture system withimage quality assurance (IQA) of the present invention in the UnisysNetwork Document Processor (NDP) platform;

FIG. 9 illustrates a preferred embodiment of the retrieval of “suspect”images using the IDX file and IQA file of FIG. 3 and image qualityrecord structure of FIG. 6;

FIG. 10 illustrates a method of retrieving image quality suspects in theimage capture system with image quality assurance (IQA) according to thepresent invention;

FIG. 11 illustrates an alternate method of retrieving image qualitysuspects in the image capture system with image quality assurance (IQA)according to the present invention; and,

FIG. 12 illustrates an alternate post-image capture embodiment of animage capture system with image quality assurance (IQA) according to thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred features of selected embodiments of this invention will now bedescribed with reference to the figures. It will be appreciated that thespirit and scope of the invention is not limited to the embodimentsselected for illustration. For example, although the present inventionwill be described with reference to the X9.37 standard and its progeny,as this appears to be the preferred financial image interchangestandard, it will be appreciated that the invention is not so limitedand that is applicable to any automated image quality assuranceimplementation regardless of the image interchange standard that isultimately adopted. Also, it should be noted that the drawings are notrendered to any particular scale or proportion. Finally, it iscontemplated that any of the configurations and materials describedhereafter can be modified within the scope of this invention.

As set forth above, although the proposed solutions to his problem haveincluded appending or embedding of image quality “flag” bits or datarecords directly into the existing check image file formats, asdiscussed above, this is an inefficient use of time and applicationprocessing time, since the vast majority of check images do not have anyquality defects present. There are other deficiencies with theseproposed methodologies as well.

For example, certain types of image defects are independent of the imagerepresentation (e.g., black/white vs. full gray scale). Examples mayinclude: 1) Images of documents that have one or more folded or torncorners, 2) images of documents where the document is skewed, and 3)images of overlapped or “piggybacked” documents. In these scenarios, thesame image quality flag(s) will be “set” independently of the imagerendition, since the defect will show up in all images of that document.Currently known systems and methods such as that of FIG. 1, where imagequality flags are stored for each image file independently do notprovide any method to consolidate “common” image defects for eachdocument independent of the image renditions being generated.

In addition, currently known methods do not allow for the easy detectionof “temporal” image quality defects—i.e., defects that may only affect asubset of a number of documents, or a subset of a batch of documents,and then resolve itself over a period of time. One type of “temporal”image defect is the presence of horizontal “streaks” in the documentimage due to dirt on the digital camera's scan window or optics. In manycases the dirt is present in the camera system's field of view for onlyfor a short period of time and is eventually removed by the wipingaction of the paper documents against the scan window. This type ofimage quality defect will cause a sequence or range of check images toexhibit the same image quality defect. As known methods such as thatdisclosed in FIG. 1 store the image quality flags specific to a documentimage within the image file, versus a range or batch of documents, themethod does not provide direct support for identifying temporal imagequality defects.

Furthermore, as check processing is normally performed by partitioningdocuments into “batches” in order to facilitate processing workflows andbalancing operation, most image-enabled document processing applicationsoftware involves the processing of batches of checks. Neither theaforementioned proposed method nor other known methods provide aconsolidated summary of image quality defects associated with the batchof images that have been captured/imaged.

Finally, none of the known IQA methodologies allow for storing thecriteria used to determine the value of each image quality flag (i.e.,whether the flag is set or not). The values of image quality flags aregenerally determined by comparing some image measurements (or metrics)against some set of rules that compare the metric(s) to one or moreparameter settings. As an example, the compressed image file size (inkilobytes) can be compared to a “maximum” or “minimum” image file sizeparameter. The result of the comparison (i.e., whether the compressedimage file size is greater than, less than, or equal to the “maximum” or“minimum” image file size parameter) will be used to determine whetherthe “image file size defect flag” is set. Prior IQA methodologies suchas shown in FIG. 1 do not provide information on the parameters used indetermining the state of each image quality flag.

Automated Image Quality Assurance (IQA)

An embodiment of the automated image quality assurance (IQA) system andmethod of the present invention that addresses all of the aforementionedshortcomings of prior known IQA methodologies will now be discussed withreference to FIG. 2.

The image capture document processing system 200 begins at 202 with animage capture process 202. As known to those skilled in the art, as eachdocument in a batch of documents is imaged, one or more imagerenditions, e.g., JPEG and CCITT Group 4, are preferably created at 202for the front and rear of each document and then stored to separatefiles, e.g., a front image file (FIM) 206, a rear image file (RIM) 208,a second front image file (FI2) 210, a second rear image file (RI2) 212,by the image file generation process 204. (Although preferably imagerenditions are generated for both sides of a document, it will beappreciated that in certain image processing platforms, image renditionsmay be generated only for one side of the document). It will beunderstood by those skilled in the art that any image capture process202 and image file generation process 204 may be used, and as suchprocesses are well-known to those skilled in the art, no furtherdiscussion is needed.

An image index file (IDX) 214 is created so that any of theaforementioned individual image files may be accessed by extracting thedata stored therein. Finally, an end-of-file (EOF) semaphore file 216 iscreated to signal the completion of processing for a batch of documents

Image data generated from the image capture process 202 for each imageis then analyzed by the IQA metric generation process 218 to provideselected image metrics which may be used to assess image quality of thecaptured images. As discussed above, these image metrics may include anyor all of the following: image metric data, e.g., height and width;compressed image packet size; image gray level histograms; uncompressedimage data; image skew angle; hardware/software feed check errors;and/or other transport status/error detection information, and may beused alone or in any combination thereof to generate specific imagequality “flags” (discussed in more detail below). Other image metricsthat are known to those skilled in the art may also be included in theIQA metric generation process 218.

In accordance with one embodiment of the present invention, an optionaldocument metrics process 220 provides relevant information about thetype and physical dimensions of the documents being processed. Examplesof document measure metrics may include beam-of-light (BOL)-“late”signal, document spacing error, double document, and similar documentmeasures. This information may be obtained from track control PC 804(FIG. 8), or track control logic and sensors (not shown) located in thedocument transport (e.g., document processor track hardware 802 (FIG.8)). The optional document metrics process 220 might be used if imagequality assurance is performed in real-time during image capture;however, the information provided by this process 220 would not beavailable in post-capture implementations of the present invention.

For each image quality defect to be detected, one or more of the imagemetrics generated by the IQA Metric Generation Process 218 and,optionally, the document metrics provided by the Document MetricsProcess 220 are then compared at IQA Rules Process 222 against aselected image quality metric setting or threshold, or some combinationsof image quality metric thresholds, from an IQF Parameter File 224 inorder to determine whether a particular image metric “passed” or“failed.” The IQF Parameter File 224 is preferably generated prior tothe start of the image capture process 202, preferably by an imagequality configuration application that provides a human interface todisplay and modify the image quality settings and thresholds. The IQFParameter File 224 includes at least customized image quality metricthresholds that have been predefined or preselected (e.g., by themanufacturer, the user, or a third party value-added reseller) and ispreferably stored in an image capture server PC (e.g., ICS PC 810 inFIG. 8) as an image quality flag initialization file (IQF.INI)(discussed with reference to FIG. 8 below).

At the beginning of each batch of documents, an IQF file 230 is createdwith an associated IQF header record 306 (see, FIG. 3) that contains theimage quality metric thresholds from the IQF Parameter File 224. Shouldthe image data for any of the captured document images fail thepredefined image quality metric threshold test (e.g., not equal orexceed the threshold) at 222, an IQA “flag” (226) will be generated.This flag 226 will, in turn, be used to generate at IQF RecordGeneration Process 228 a record entry in an IQF file 230. The IQF RecordGeneration Process 228 creates in IQF file 230 a record entry for eachdocument in the batch that is suspected of having an image qualitydefect (i.e., one or more image quality flags 226 have been “set” forone or more of the image renditions associated with that document).Therefore, if five documents in a batch have been flagged as havingsuspect image quality (on one or more image renditions), five recordentries will be placed into the IQF file 230 for that batch of images.The record entries in the IQF file 230 in turn contain image indexinformation pointing to the suspect document in the image index file(IDX) 214 along with all the image quality flags associated with eachimage rendition of that document (e.g., CCITT, JPEG). In addition, IQFRecord Generation Process 228 will indicate that image quality waschecked for that document, and that it has a corresponding “flagged” IQFfile record, by initializing a field in record 310 for that documentbefore record 310 is written to the image index file (IDX) 214.Preferably, this is done by setting a global IQA flag 300 in thedocument record 310 before record 310 is written to image index file(IDX) 214. In addition, image quality record index field 302 will beinitialized to include a reference to the corresponding record entry inthe IQF file 230. Further details regarding the format of the IQF file230 and IDX file 214 will be discussed below with reference to FIG. 3.

The IQF flags and parameters 304 for that batch of documents are thenstored at 230 for later retrieval of image quality suspects, and theimage index file (IDX) 214 is preferably modified to indicate that imagequality has been checked for that batch of documents. Image qualityinformation is made accessible to a document imaging application (notshown) by having the document imaging application “scan” only thoserecord entries present in the IQF file 230 after the batch is released(via the EOF file semaphore 216). Further discussion of the retrieval ofimages having suspect image quality will be discussed with reference toFIGS. 10 and 11.

In a preferred embodiment of the present invention, if the imaginghardware or software used to carry out the image capture process 202does not support detection of particular imaging quality metrics, theimage capture process 202 will automatically amend IQF Parameter File224 to disable the detection for these imaging quality metrics.(discussed in more detail with reference to FIG. 5 below)

Optionally, if a user is not interested in conducting image qualityassurance for a particular batch of documents, the IQF file 230 can beignored by the document imaging application. This is preferablyaccomplished through parameter settings located in the image parametersinitialization file of IQF Parameter File 224 (discussed below). It willbe appreciated that this allows the benefit of the addition or exclusionof an IQF file that in no way impacts those current document imagingapplications that use the existing image file structures (IDX, FIM, FI2,RIM, RI2, etc.). Thus the automated image quality assurance of thepresent invention can be conducted without modification of documentimaging applications.

IQF File Structure and Modified IDX File Structure

Modified IDX File Structure

In accordance with a preferred embodiment of the present invention, andwith reference to FIG. 3, the file structure of image index file IDX 214is modified such that each IDX record 310 contains a single “global”image quality flag 300 and image quality record index field 302.Preferably, the “global” image quality flag 300 comprises one byte andis at a location in each IDX record 310 in the image index file IDX 214that was reserved in previously created versions of the IDX file 214. Inaddition, the image quality record index field 302 preferably comprisesa 32-bit (4-byte) record field at locations that were reserved inpreviously created versions of the IDX file 214.

As set forth above, the “global” image quality flag 300 is used toindicate whether image quality was checked for a document and, if so,whether one or more image renditions “failed” the image quality tests.In one embodiment, a value of zero (0) is used to indicate that thedocument was not checked for image quality, and a non-zero value is usedboth to indicate that it was checked and to represent whether it passedor failed (e.g., 1=failed, on one or more image renditions, 2=passed).Of course, it will be understood that any other similar representationsmay be used to provide this same information.

The image quality record index field 302 is used to point to (i.e.,index into) the appropriate record 308 in the IQF file 304 that containsthe document that has one or more image quality errors. The particularone of the image quality record entries 308 (pointed to by the imagequality record index field 302) will then contain the image quality flagdata for all image renditions associated with the document.

IQF File Structure—Header Structure

Referring to FIGS. 3 and 4, IQF file 304 comprises a header record 306that contains at least the parameter settings 404 for the “pass/fail”criteria associated with each image quality flag (i.e., the image metricthreshold values extracted from the IQF Parameter File 224). Inaddition, in one embodiment of the present invention, the IQF headerrecord 306 includes image file set information 402, reserved fields 406to allow for additional data in future implementations of image qualityassurance, the particular version level of the IQA being used 408, and achecksum field 410 to allow verification that the IQF header record datahas not been corrupted. In one embodiment, the IQF header record 306comprises 512 bytes.

The parameter settings 404 that are extracted from the IQF parameterfile 224 (e.g., IQF.INI) preferably include those fields as seen in FIG.5. In one embodiment, the parameter settings 404 comprise 100 bytes ofthe IQF header record.

Referring to FIG. 5, field 502 is an image quality parameter field thatcan be “toggled” to allow a user or a value-added reseller of imagingapplications to disable the creation of image quality flags if, forexample, the user is not interested in conducting image qualityassurance for a particular batch of documents. Again, this allows thebenefit of the addition or exclusion of an IQF file withoutimpacting/modifying the value-added reseller's (or other user's) currentdocument imaging applications that use the existing image filestructures (IDX, FIM, FI2, RIM, RI2, etc.).

In the case of document-processing applications, field 504 is preferablyused to delineate the type of document transport that was used togenerate the imagery that is undergoing IQA analysis. Field 506 includesa series of bits that define the image quality flags that have beenenabled by the software and/or hardware on which the image qualityassurance system of the present invention is running. One embodiment ofthe bit string definitions for field 506 is shown in Table I below:

TABLE I Bit Description Bit 0: Enable X9.37 0 = Do not test for apartial image “Partial Image” condition. 1 = Set the “Partial Image”Quality Flag when a partial image condition is detected. Bit 1: EnableX9.37 0 = Do not test for excessive image skew. “Excessive 1 = Set the“Excessive Image Skew” Image Skew” Quality Flag when an excessive imageskew condition is detected. Bit 2: Enable X9.37 0 = Do not test forpiggyback image “Piggyback condition. Image” 1 = Set the “PiggybackImage” Quality Flag when a piggyback image condition is detected. Bit 3:Enable X9.37 0 = Do not test for too light or too dark “Too Light Orconditions. Too Dark” 1 = Set the “Too Light Or Too Dark” Quality Flagwhen a too light or too dark condition is detected. Bit 4: Enable X9.370 = Do not test for streaks and/or bands. “Streaks And Or 1 = Set the“Streaks And Or Bands” Bands” Quality Flag when streaks and/or bands aredetected. Bit 5: Enable X9.37 0 = Do not test for minimum image size“Below Minimum 1 = Set the “Below Minimum Image Image Size” Size”Quality Flag when an image size is below an acceptable value, as definedby the ”Minimum Compressed Packet Size” Image Quality Threshold for thisimage rendition. Bit 6: Enable X9.37 0 = Do not test for maximum imagesize. “Exceeds Maximum 1 = Set the “Exceeds Maximum Image Image Size”Size” Quality Flag when an image size is above an acceptable value, asdefined by the ”Maximum Compressed Packet Size” Image Quality Thresholdfor this image rendition. Bits 7-19: X9.37 0 = Reserved for emergingX9.37 Reserved image quality technologies.

It will be appreciated that bits 0-6 of image quality enabled flags 506comprise image quality flags as defined under the X9.37 standard, whilebits 7-19 are for the reserved X9.37 image quality flags. It also willbe appreciated that the particular order of the bits within the bitstring, and the length of both the bits and bit string, are merelyexemplary. Preferably, these image quality enabled flags are set to zero“0” if no image quality conditions are to be reported for any imagerendition of the document, and to one “1” if the image quality conditionis to be reported. One skilled in the art will appreciate that thesesettings are merely exemplary and any similar flag settings may be usedinstead to represent the testing requirements for the image renditions.

However, in a preferred embodiment of the present invention, the imagequality enabled bit flags 506 comprise an additional 76-bits as shown inTable II below, for a total of 96-bit (12-byte) string. These additionalimage quality flags have been defined by Unisys Corporation, theassignee of the present invention, and are based on measures generatedby its NDP platform software and/hardware (discussed in more detailbelow). Again, the particular order of the bits within the bit string,and the length of both the bits and bit string, are merely exemplary:

TABLE II Bit Description Bit 20: Enable Unisys 0 = Do not test forfeed-check conditions. “Feed-check” 1 = Set the “Feed-check” QualityFlag when a feed-check condition is detected (NDP850-NDP2000 transportsonly). Bit 21: Enable Unisys 0 = Do not test for BOL Late conditions.“BOL Late” 1 = Set the “BOL Late” Quality Flag when a BOL Late conditionis detected. Bit 22: Enable Unisys 0 = Do not test for framing errorconditions. “Framing Error” 1 = Set the “Framing Error” Quality Flagwhen a Framing Error condition is detected. Bit 23: Enable Unisys 0 = Donot test for minimum document height. “Below Minimum 1 = Set the “BelowMinimum Document Document Height” Height” Quality Flag when an imagedocument height is below an acceptable value, as defined by the ”MinimumDocument Height” Image Quality Threshold. Bit 24: Enable Unisys 0 = Donot test for maximum document height. “Exceeds Maximum 1 = Set the“Exceeds Maximum Document Document Height” Height” Quality Flag when animage document height is above an acceptable value, as defined by the”Maximum Document Height” Image Quality Threshold. Bit 25: Enable Unisys0 = Do not test for minimum document length. “Below Minimum 1 = Set the“Below Minimum Document Document Length” Length” Quality Flag when animage document length is below an acceptable value, as defined by the”Minimum Document Length” Image Quality Threshold. Bit 26: Enable Unisys0 = Do not test for maximum document length. “Exceeds Maximum 1 = Setthe “Exceeds Maximum Document Document Length” Length” Quality Flag whenan image document length is above an acceptable value, as defined by the”Maximum Document Height” Image Quality Threshold. Bits 27-95: UnisysReserved for emerging Unisys image quality Reserved technologies.

In the preferred embodiment of the present invention, if an X9.37 flagbit is enabled that requires additional image quality conditions to bedetected in order to effect the detection of that particular imagequality metric, the image capture software will automatically enable thecorresponding platform-specific image quality enabled flags. Forexample, when the X9.37 “partial image” image quality flag is enabled(e.g., bit 0 in Table I), the image capture software will enable theUnisys “beam of light (BOL) late” (e.g., bit 21 in Table II) and“framing error” (e.g., bit 22 in Table II) image quality flags.

In addition, as set forth above, if the hardware or software used tocarry out the image quality assurance of the present invention does notsupport the detection of any of the particular imaging quality metrics,image capture software can disable in this field the corresponding imagequality enabled flag bit. It will be appreciated from Table I thatselected bits (i.e., bits 7-19) may be reserved for emergingX9.37-related image quality technologies. Similarly, selected bits(i.e., bits 27-95) may be reserved for emerging image qualitytechnologies being developed by Unisys Corporation, the assignee of thepresent invention. It will be appreciated however, that the reservedbits are optional and not mandatory in the present invention.

Finally, parameter settings 404 include fields 508 through 532, whichcomprise the customized image quality metric thresholds that have beenpreviously defined or preselected (e.g., by the transport manufactureror a value-added reseller of imaging applications). These image qualitymetric thresholds are preferably only set if the corresponding imagequality enabled flag bits (e.g., as shown in TABLE I) are enabled.Examples of the customized image quality metric thresholds may includeminimum CCITT compressed packet size, maximum CCITT compressed packetsize, minimum JPEG compressed packet size, maximum JPEG compressedpacket size, minimum document height, maximum document height, minimumdocument length, and maximum document length. It will be appreciatedthat additional metric thresholds may be included depending upon thehardware and software on which the image quality assurance of thepresent invention is running. For example, in the case were the imagecapture process 202 is carried out using a dual filter camera,additional thresholds may include minimum auxiliary CCITT compressedpacket size, maximum auxiliary CCITT compressed packet size, minimumauxiliary JPEG compressed packet size, and maximum auxiliary JPEGcompressed packet size. Field 534 preferably includes expansion bits toallow for the addition of future image quality metric thresholds as theyare developed or become available (although this is not required in thepresent invention).

IQF File Structure—“Record” Structure

After image header record 306, an image quality “record” 308 may begenerated for IQF file 304. As discussed above, an image quality record308 is only generated for each document D having one or more imagequality errors for any and all image renditions for that document D.Preferably, each image quality record 308 is 512 bytes in order to allowfor future expansion and emerging image conditions (although this is notrequired in the present invention). A preferred embodiment of thestructure of an image quality record 308 in IQF file 304 is shown inFIG. 6.

Image quality record 308 for a document D preferably includes an IDXoffset “field” 602 that defines the offset of that document in the IDXfile. The IDX offset field defines the beginning of the document recordin the IDX file that can be used to retrieve the images associated withdocument D, as shown in FIG. 9. After IDX offset “field” 602, globalimage quality condition “field” 604 preferably includes a bit stringindicating the image renditions (e.g., FIM, RIM, FI2, RI2) that havereported image quality conditions.

In one embodiment of the present invention, global image qualitycondition “field” 604 includes a 16-bit (2 byte) string as defined inTable III below, although it will be appreciated that the particularorder of the bits within the bit string, and the length of both the bitsand bit string, are merely exemplary:

TABLE III Bit Definition Bit 0: Front 1 0 = No image quality conditionswere reported Image Quality (FIM) for the 1^(st) “front image” renditionof the document. 1 = One or more image quality conditions were reportedfor the 1^(st) “front image” rendition of the document. Bit 1: Rear 1 0= No image quality conditions were reported Image Quality (RIM) for the1^(st) “rear image” rendition of the document. 1 = One or more imagequality conditions were reported for the 1^(st) “rear image” renditionof the document. Bit 2: Front 2 0 = No image quality conditions werereported Image Quality (FI2) for the 2^(nd) “front image” rendition ofthe document. 1 = One or more image quality conditions were reported forthe 2^(nd) “front image” rendition of the document. Bit 3: Rear 2 0 = Noimage quality conditions were reported Image Quality (RI2) for the2^(nd) “rear image” rendition of the document. 1 = One or more imagequality conditions were reported for the 2^(nd) “rear image” renditionof the document. Bits 4-15: Reserved Reserved for future imagerenditions.In a preferred embodiment, bits 4-15 are reserved for future imagerenditions such as region-of-interest images or alternate compressionschemes. Preferably, these global image quality condition flags are setto zero “0” if no image quality conditions were reported for theparticular image rendition of the document, and to one “1” if one ormore image quality conditions were reported. One skilled in the art willappreciate that these settings are merely exemplary and any similar flagsettings may be used instead to represent the testing results of theimage renditions.

Image quality record 308 for a document D also preferably includes imagequality conditions 606, 608, 610 and 612. Image quality conditions 606,608, 610 and 612 include specific information regarding the presence andtype(s) of image quality conditions that are generated for any and allimage renditions for that document D and comprise separate “sub-records”for each of the image renditions of a document. Image file generationprocess 204 populates those sub-records for which a corresponding imagerendition exists for document D. Thus, for example, if image filegeneration process 204 generates a FIM image rendition, image qualityrecord 308 will populate a Front 1 image quality conditions sub-record606; if image file generation process 204 generates an RIM imagerendition, image quality record 308 will populate a Rear 1 image qualityconditions sub-record 608; if image file generation process 204generates an FI2 image rendition, image quality record 308 will populatea Front 2 image quality conditions sub-record 610; if image filegeneration process 204 generates an RI2 image rendition, image qualityrecord 308 will populate a Rear 2 image quality conditions sub-record612, and so on. Each of these image quality conditions sub-records, inturn, preferably includes specific information about a particulartype(s) of image quality condition(s) (if any) that was generated at IQArules process 222 for that particular image rendition. A preferredembodiment of the structure of these generated conditions 606, 608, 610and 612 may be understood with reference to FIG. 7 (discussed below).Finally, image quality “record” 308 for a document preferably includesreserved bytes 616 in order to allow for future expansion and emergingimage conditions (although this is not required in the presentinvention).

FIG. 7 shows a preferred embodiment of the structure of any of the imagequality conditions sub-records 606, 608, 610 and 612 of the imagequality record 308. Each image quality conditions sub-record structure700 includes a global image quality flag 702, which is preferably anASCII code that indicates whether the particular image rendition wastested for any of the conditions including those related to X9.37 imagequality definitions such as set forth in Appendix A, and, if so, whetherany image quality suspect errors were reported. In a preferredembodiment, a tri-stated flag 702 is set to zero “0” if the image wasnot tested for any of the image quality conditions, one “1” if the imagewas tested and one or more image quality conditions were reported, ortwo “2” if the image was tested and no image quality conditions werereported. One skilled in the art will appreciate that these settings aremerely exemplary and any similar flag settings may be used instead torepresent the testing results of the image renditions.

Following global image quality flag 702, image quality conditionssub-record structure 700 sets forth a number of specific suspect imagequality conditions 704 that may be generated for the particular imagerendition during IQA process rules 222 when some aspect of the imagedoes not pass the predefined threshold set forth in IQF parameter file224 and image quality bit fields 708, which preferably include at leastthe bit fields set forth in Tables V and VI below. Each of the suspectimage quality conditions 704 preferably comprises an ASCII code, whilethe image quality bit fields 708 preferably comprises a bit string. Thesuspect image quality conditions 704, and image quality bit fields 708in conjunction with the image quality enabled flags 506 (FIG. 5), areused to indicate whether a particular image rendition was tested for aspecific image quality condition and, if so, whether the specific imagequality condition was detected.

More specifically, as set forth above, image quality enabled flags 506preferably comprise a bit string that defines the image quality flagsthat have been enabled by the software and/or hardware on which theimage quality assurance system of the present invention is running. Thusfor each image quality condition to be tested, the corresponding bit inimage quality enabled flags 506 indicates whether the images were tested(enabled) for that condition. The corresponding bit in 708 is then alsoset to indicate whether the condition was detected, if the image wastested for the condition. Finally, image quality conditions 704 are acombination of the states of a subset, which may include the entire set,of the image quality enabled flags 506 and corresponding bits 708, andare used to indicate whether the test was conducted for the specificsuspect image quality condition, and if so, whether the condition waspresent. Image quality conditions 704 are preferably represented as atri-state ASCII code, as further discussed below.

As set forth above, in one embodiment of the present invention, theimage quality enabled flags 506 are set to zero “0” to indicate that noimage quality conditions are to be reported for any image rendition ofthe document, and to one “1” to indicate that the image qualitycondition is to be reported. In this embodiment, the corresponding bit708 is preferably set to one “1” if the condition was tested and ispresent, and set to zero “0” otherwise (i.e., the condition was nottested or the condition was tested, but not present). The resultingimage quality conditions 704 are then preferably indicated in ASCII codeas follows in Table IV:

TABLE IV State of Condition 506 708 704 Condition not tested 0 0 “0”Condition tested, and detected 1 1 “1” Condition tested, but notdetected 1 0 “2”

Thus, in this embodiment, the ASCII code bits are set to the coderepresenting the character zero “0” if a test for the specific suspectimage quality condition was not conducted, the code representing thecharacter one “1” if the test was conducted and the specific suspectimage quality condition is present, or the code representing thecharacter two “2” if the test was conducted and the specific suspectimage quality condition was not present. Of course, one skilled in theart will appreciate that these settings are merely exemplary and anysimilar encodings may be used instead to represent the testing resultsof the image renditions. Further, it will be understood by those skilledin the art that as the EBCDIC character set is the preferred encodingset forth in the X9.37 standard, it may be used instead of ASCII.

The “list” of suspect image quality conditions 704 preferably includesthe following: “Partial image” condition (which indicates whether only aportion of the image rendition is represented digitally with the otherportion is suspected of being either missing or corrupt); “excessivedocument skew” condition (which indicates if the image skew exceeds anacceptable value, such value generally being specific to definedrequirements and/or constraints in an imaging application); “piggybackimage” condition (which indicates that the image rendition may beextended, obscured, or replaced by the image(s) of additionaldocument(s), which may occur when two or more documents are fed togetherand captured as one document); “too light or too dark image” condition(which indicates if the image is too light or too dark. The value ofthis condition is generally specific to the defined requirements and/orconstraints in an imaging application); “streaks and or bands” condition(which indicates if the image is likely corrupted due to streaks and/orbands, such as might be caused by dirt, dust, ink, or debris on a lensor in the optical path); “below minimum image size” condition (whichindicates if the size of the compressed image is below an acceptablevalue, generally being defined or constrained by the imagingapplication, and which is further defined by the “minimum compressedpacket size” image quality threshold); and, “exceeds maximum image size”condition (which indicates if the size of the compressed image is abovean acceptable value, generally being defined or constrained by theimaging application, and which is further defined by the “maximumcompressed packet size” image quality threshold).

In one embodiment of the present invention, image quality conditionssub-record structure 700 also includes additional reserved bytes 706 toallow for future expansion an emerging image conditions (although thisis not required in the present invention). As shown in FIG. 7, thenumber of reserved bytes matches the number of reserved image qualityinformation fields in the X9.37 standard. As shown in FIG. 7, the numberof bytes may be thirteen (13).

Image quality bit fields 708 preferably include at least the bit fieldsset forth in Table V. Image quality bit fields 708 can be used to morerapidly evaluate if any of a multiplicity of enabled conditions weredetected for an image rendition; i.e., without having to examine each ofthe ASCII image quality conditions 704.

It will be appreciated that bits 0-6 of image quality bit fields 708reflect image quality conditions 704, while bits 7-19 reflect imagequality conditions 706. It also will be appreciated that the particularorder of the bits within the bit string, and the length of both the bitsand bit string, are merely exemplary:

TABLE V Bit Description Bit 0: Partial 0 = Entire image is present, orcondition Image Flag not tested. 1 = Portion of the image is suspectedto be missing. Bit 1: Excessive 0 = Image skew does not exceed anDocument Skew acceptable value, or condition not tested. Flag 1 = Imageskew exceeds an acceptable value. Bit 2: Piggyback 0 = Piggybackcondition not present, Image Flag or not tested. 1 = Piggyback conditionpresent. Bit 3: Too Light 0 = Too Light or Too Dark condition not or TooDark Flag present, or not tested. 1 = Too Light or Too Dark conditionpresent. Bit 4: Streaks 0 = Streaks and/or bands not detected, and/orBands Flag or not tested. 1 = Streaks and/or bands detected.. Bit 5:Below 0 = The compressed image is not below an Minimum Image acceptablevalue, or condition not tested. Size Flag 1 = The compressed image isbelow an acceptable value. Bit 6: Exceeds 0 = The compressed image isnot above Maximum Image an acceptable value, or condition not tested.Size Flag 1 = The compressed image is above an acceptable value. Bits7-19 0 = Reserved

However, in a preferred embodiment of the present invention, the imagequality bit fields 708 comprise an additional 76-bits as shown in TableVI below, for a total of 96-bit (12-byte) string. These additional imagequality flags have been defined by Unisys Corporation, the assignee ofthe present invention, and are based on measures generated by its NDPplatform software and/hardware (discussed in more detail below). Again,the particular order of the bits within the bit string, and the lengthof both the bits and bit string, are merely exemplary:

TABLE VI Bit Description Bit 20: Feed- 0 = “Feed-check” condition notcheck detected, or condition not tested. 1 = “Feed-check” conditiondetected. Bit 21: BOL Late 0 = “BOL Late” condition not detected, orcondition not tested. 1 = “BOL Late” condition has been detected. Bit22: Framing 0 = “Framing Error” condition not Error detected, orcondition not tested. 1 = “Framing Error” condition has been detected.Bit 23: Below 0 = A document height greater than Minimum the “MinimumDocument Height” has been Document Height detected, or condition nottested. 1 = A document height lower than or equal to the “MinimumDocument Height” Image Quality Threshold has been detected. Bit 24:Exceeds 0 = A document height lower than Maximum the “Maximum DocumentHeight” has been Document Height detected, or condition not tested. 1 =A document height greater than or equal to the “Maximum Document Height”Image Quality Threshold has been detected. Bit 25: Below 0 = A documentlength greater than Minimum the “Minimum Document Length” has beenDocument Length detected, or condition not tested. 1 = A document lengthlower than or equal to the “Minimum Document Length” Image QualityThreshold has been detected. Bit 26: Exceeds 0 = A document length lowerthan Maximum the “Maximum Document Length” has been Document Lengthdetected, or condition not tested. 1 = A document length greater than orequal to the “Maximum Document Length” Image Quality Threshold has beendetected. Bits 27-95 0 = Reserved.

As set forth in Table VI, these additional image quality flag bitspreferably include the following: image quality flag bit 20 representingthe condition of feed-check (currently only available on high-speedUnisys NDP platforms such as the NDP850 and NDP2000, this condition caninclude any of the following, double document, over-length document, orunder-spaced document(s)); image quality flag bit 21 representingbeam-of-light (BOL) late (which occurs if, at the time that a camera iscommanded to start looking for the leading edge of a document, the videobackground exceeded the maximum video background threshold, which wouldindicate that the camera is already receiving document data and,therefore, the document may not be framed correctly); image quality flagbit 22 representing a framing error (which occurs if the framing circuithas not detected the leading/trailing of the document within the maximumtime allowed); bits 23 and 24 representing that the document height isbelow a minimum threshold or exceeds a maximum threshold, respectively;and, finally, bits 25 and 26 representing that the document length isbelow a minimum threshold or exceeds a maximum threshold, respectively.Flag bits 27-95 are reserved for future additional image quality flagsthat may be developed from measures generated from the Unisys NDPplatform or other document processing platform, or for other imagequality flags. In a preferred embodiment, these image quality flags areset to zero “0” if the image quality condition is not present or if theimage was not tested for this condition. The flag is set to one “1” toindicate that that particular image condition is present. One skilled inthe art will appreciate that these settings are merely exemplary and anysimilar flag settings may be used instead to represent the testingresults of the image renditions.

The preferred file structure of IQF file 304 is thus as follows:

IQF_HEADER_STRUCTURE Annotation File_Name File_DirectoryImage_Quality_Metric_Thresholds Create_Image_Quality_Flag Transport_TypeImage_Quality_Enabled_Flags X9.37_Image_Quality_Enabled_FlagsX9.37_Quality_Flag_1 X9.37_Quality_Flag_2 ... X9.37_Quality_Flag_mmUnisys_Image_Quality_Enabled_Flags Unisys_Quality_Flag_1Unisys_Quality_Flag_2 ... Unisys_Quality_Flag_nn [Reserved for FutureUse] Image_Quality_Metric_1_Threshold Image_Quality_Metric_2_Threshold... Image_Quality_Metric_pp_Threshold [Reserved for Future Use][Reserved for Future Use] IQF_Version_Level ChecksumEND_IQF_HEADER_STRUCTURE IQF_RECORD_STRUCTURE .IDX_File_OffsetGlobal_Image_Quality_Conditions_For_Document_DGlobal_Image_Quality_Flag_For_Front_Image_Document_DGlobal_Image_Quality_Flag_For_Rear_Image_Document_DGlobal_Image_Quality_Flag_For_Front_2_Image_Document_DGlobal_Image_Quality_Flag_For_Rear_2_Image_Document_D [Reserved forFuture Use] Image_Quality_Conditions_For_FIM_Document_DASCII_Global_X9.37_Image_Quality_FIM_Document_DASCII_Image_Quality_Conditions_FIM_Document_DASCII_Image_Quality_Condition_1_FIM_Document_DASCII_Image_Quality_Condition_2_FIM_Document_D ...ASCII_Image_Quality_Condition_mm_FIM_Document_DImage_Quality_Bit_Fields_For_FIM_Document_DX9.37_Image_Quality_Bit_Field_Flags X9.37_Quality_Flag_1X9.37_Quality_Flag_2 ... X9.37_Quality_Flag_mm [Reserved for Future Use]Unisys_Image_Quality_Bit_Field_Flags Unisys_Quality_Flag_1Unisys_Quality_Flag_2 ... Unisys_Quality_Flag_nn [Reserved for FutureUse] Image_Quality_Conditions_For_RIM_Document_DImage_Quality_Conditions_For_FI2_Document_DImage_Quality_Conditions_For_RI2_Document_DReserved_For_Future_Expansion END_IQF_RECORD_STRUCTUREwhere: “mm” represents the total number ofX9.37_Image_Quality_Enabled_Flags, “nn” represents the total number ofUnisys_Image_Quality_Enabled_Flags, and “pp” represents the total numberof Image_Quality_Metric_Thresholds.

Unisys NDP Embodiment

FIG. 8 illustrates a preferred embodiment of an implementation of theimage capture system with image quality assurance (IQA) of the presentinvention on the Unisys Network Document Processor (NDP) platform. TheUnisys NDP series, including the NDP 300/600, 850, 1150, 1600, 1825, and2000 are all commercially available from Unisys Corporation, Unisys Way,Blue Bell, Pa., 19424. Only the portions of the platform relevant to thepresent invention will be discussed.

As seen in FIG. 8, documents are physically processed through thetransport hardware 802 of a Unisys NDP document processors under thecontrol of track control PC 804. Track control PC 804 provides sortercontrol of document transport hardware 802, and includes trackapplications, such as inclearings, proof of deposit, and remittanceoperations, and system software (not shown), which in a preferredembodiment of the present invention, is WINDOWS NT®, WINDOWS® 2000, orWINDOWS® XP-based system software. The system software preferablyincludes Unisys Common Application Programming Interface, or CAPI, whichis a common application programming interface that enables the sameapplication software to be used across multiple transport platforms.

Image capture subsystem 806 provides image server and capturecapabilities and interfaces with the document transport hardware 802 toreceive images moved by document transport 802 and to store them inappropriate files (e.g., FIM, RIM, FI2, RI2). Image capture subsystem806 generally comprises both hardware and software, including imagingmodule hardware 808, having a camera system (not shown) for capturingimages, and image capture server (ICS) PC 810 for processing and storingof the images.

In accordance with a preferred embodiment of the present invention, theimage capture server (ICS) PC 810 receives the captured image data fromimaging module hardware 808 (image capture process 202), processes theimage data for storage (image file generation process 204), and thencarries out the IQA Metric Generation Process 218, optional DocumentMetrics Process 220, IQA Rules Process 222, and IQF Record Generationprocess 228.

The metrics of the present invention are generated in real-time by theUnisys NDP platform and can be used to provide the image quality flagsproposed by the X9.37 standard (as set forth above). The metricsgenerated by the Unisys NDP platform may originate from either theplatform hardware (e.g., track control PC 804, image module hardware 808), or from system software (e.g., CAPI, ICS PC 810 software). Accordingto the present invention, currently available metrics that might beconsidered either separately or in combination to generate image qualityflags include the following hardware-generated metrics, such as:compressed image packet size; document image height and length; documentskew; Beam-of-light (BOL) “late” signal; framing error; leading/trailingedge; feed check status (including piggyback items, over length items,document spacing errors); and compressor hardware errors.Software-generated metrics might include feed check detected; zero (0)byte images; comparison of document front and rear image dimensions;disk storage full (out of space to store image files); failure to storeimage; and CAPI document complete status.

An exemplary implementation of the structure of the IQF file 304including descriptions for the NDP platform is attached hereto asAppendix B.

Retrieval of Image Quality Suspects

It will be appreciated from the foregoing that suspect images can easilybe located by scanning through the record entries of IQF file 304.Retrieval of these suspect images is accomplished by using the IDX fileoffset field 602 in the image quality record 308 to index into the IDXfile, which in turn, provide pointers into the image files.Alternatively, identification of the suspect images may be accomplishedby using the image quality record index field 302 stored in the IDXrecord 310 to index into the image quality record 308 to determine whichof the images are suspect.

More particularly, FIGS. 9 and 10 (with reference to FIG. 3) illustratesone method of retrieving image quality suspects in the image capturesystem with image quality assurance (IQA) according to the presentinvention. The IQF file 304 is read by an imaging application (notshown) at 1002 to determine whether an image quality record 308 exists,indicating that at least one document in the particular batch inquestion was flagged as having one or more image defects. If no imagequality record 308 exists, the process ends. If an image quality record308 exists (1002), the image quality record is read at 1004. All entriesin the record are reviewed by the imaging application to determine whichimage renditions have image problems as well as the type of imageproblems (1006). The imaging application will then use the IDX fileoffset 602 to index into the IDX record 310 containing the image(s)having suspect image quality (step 1008). Index pointers in the IDX filecan then be used to index into the specific suspect image files (e.g.,FIM, RIM, FI2, RI2) at step 1010. The process then returns to step 1002to determine if more image quality records exist.

Alternatively, as shown in FIG. 11 (with reference to FIG. 3), for eachrecord in the IDX file (1102) (one record for each document), the“global” image quality flag 300 in that IDX record can be read (1104) tosee if that document has been checked for image quality (1106), and ifso, whether all the images “passed” or one or more image qualityconditions were detected. If the “global” image quality flag 300 in theIDX record field indicates at 1108 that no image quality conditions weredetected, the process continues with the next document at 1102. If,however, the “global” image quality flag 300 in the IDX record indicatesat 1106 that one or more image quality conditions were detected, theimage quality record index field 302 is then used by the imagingapplication to index into the IQF file 304 to retrieve the image qualityrecord for this document and determine which image renditions for thisdocument have image quality conditions (1108). At 1110, the imagequality flag data pertinent to the imaging application are thenreviewed, and pertinent image renditions having image quality flags thatare “set” are retrieved (1112).

Automated Image Quality Assurance (IQA) in a Post-Capture ImagingEnvironment

Referring to FIG. 12, an alternative implementation of the presentinvention is shown wherein the image quality assurance system andmethodology is carried out in a post-image-capture environment. Apost-image-capture image quality assurance system and methodology mightbe needed and/or desired to screen incoming images during check imageinterchange processes. In such instance, the IQF file 1230 is alsocreated post-image capture.

In accordance with this embodiment, the image capture process 1202 andimage file generation 1204 are carried out in substantially the samemanner as discussed in FIG. 2. Similarly captured front images (FIM)1206, rear image (RIM) 1208, second front images (FI2) 1210, and secondrear image (RI2) 1212, and end-of-file (EOF) semaphore file 1216 aresubstantially identical to their counterparts in FIG. 2. Modified imageindex file (IDX) 1214 is likewise substantially identical to itscounterparts in FIG. 2.

Images stored in FIM 1206, RIM 1208, FI2 1210, and RI2 1212 are thenretrieved and decompressed at 1216 in any manner known to those of skillin the art. The retrieved and decompressed image data is then analyzedby the IQA Metric Generation Process 1218 to provide selected imagemetrics that may be used to assess image quality of the captured images.The image metrics used in 1218 are comparable to those discussed inrelation to FIG. 2, and may include any or all of the following: imagedimensional data (e.g., height and width); compressed image packet size;image gray level histograms; document skew angle; hardware/software feedcheck errors; and/or other transport status/error detection information,and may be used alone or in any combination thereof to generate specificimage quality “flags” (discussed in more detail below). Other imagemetrics that are known to those skilled in the art may also be includedin the IQA Metric Generation Process 1218.

The selected image metrics provided at 1218 are then compared at IQARules Process 1222 using a selected image quality metric setting orthreshold, or some combinations of image quality metric thresholds, fromIQF parameter file 1224, in order to determine whether a particularimage metric “passed” or “failed.” As with IQF parameter file 224, IQFparameter file 1224 preferably includes at least customized imagequality metric thresholds that have been predefined or preselected(e.g., by the manufacturer, the user, or a third party value-addedreseller).

As with the embodiment of FIG. 3, should the retrieved and decompressedimage data for any of the documents fail the predefined image qualitymetric threshold test (e.g., not equal or exceed the threshold) an IQA“flag” (1226) will be generated. This flag 1226 and the image qualitymetric thresholds from the IQF Parameter File 1224 will be used togenerate at 1228 an IQF file. The IQF file generated at 1228 contains arecord entry for each document in the batch that is suspected of havingan image quality defect (i.e., one or more image quality flags 226 havebeen “set” for one or more of the images associated with that document).The IQF file 304 for that batch of documents is then stored at 1230 forlater retrieval of image quality suspects, and the image index file(IDX) 1214 is preferably modified to indicate that image quality hasbeen checked for that batch of documents. Image quality information isthen made accessible to a document imaging application (not shown) byhaving the document imaging application “scan” only those record entriespresent in the IQF file.

It will be appreciated that the image quality assurance systems andmethods of the present invention provide for the realization ofautomated IQA on image platforms with improved access speed to imagequality suspects, and particularly those implementing the ASC X9.37standard and its progeny. The image quality assurance systems andmethods of the present invention provide a more efficient use ofapplication processing time and provide a method to consolidate “common”image defects for each document independent of the image renditionsbeing generated. Furthermore, the image quality assurance systems andmethods of the present invention provide direct support for identifyingtemporal image quality defects and a consolidated summary of imagequality defects associated with the batch of documents for which imageshave been captured. Finally, the image quality assurance systems andmethods of the present invention allow for storing in the image qualityflag file itself for easy referral, the information on the criteria andparameters used to determine the state of each image quality flag.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be understood by those skilledin the art that various changes in form and details may be made thereinwithout departing from the spirit and scope of the invention as definedin the appended claims. Thus, the breadth and scope of the presentinvention should not be limited by any of the above-described exemplaryembodiments, but should be defined only in accordance with the followingclaims and their equivalents.

APPENDIX A

Proposed X9.37—Image Quality Conditions:

-   1. Global Image Quality (is there any defect detected for this    image)-   2. Partial Image-   3. Excessive Document Skew-   4. Piggyback Image-   5. Too Light or Too Dark-   6. Streaks and or Bands-   7. Below Minimum Image Size-   8. Exceeds Maximum Image Size

APPENDIX B

IQF_Header_Record Name Description Annotation Data specified by the CAPIiImgAnnotate or iImgAnnotateSA Property when the GoReadyToProcess Methodwas invoked. This Property defines the application annotation data thatis stored in the header record of all future image files. Theapplication can use this data to keep information such as business day,type of work, or run number. FileName DOS file name without extension.This is the name used during transport capture. FileDirectory Directoryspecified by the iImgImageDirectory Property when the GoReadyToProcessMethod was invoked. This is the directory used during transport capture.Image Quality See “Image Quality Metric Thresholds” Metric Thresholdsdefinition below. Reserved Reserved for future expansion Version VersionIndicator. 16-bit integer indicating the version of the header record.Value is assigned as follows: Version 200 = Original version (compatiblewith version 200 of the IDX file). Checksum Addition of the first 1032-bit unsigned integers into a 16-bit unsigned integer initialized tozero.

Image_Quality_Metric_Thresholds (100 bytes in IQF_Header_Record) NameDescription Create Image 0 = No Quality Flags 1 = Yes Transport Type 0 =Unknown 1 = 300 ips (NDP1600-NDP2000) 2 = 150 ips (NDP850-NDP1150) 3 =100 ips downstream (NDP250-NDP600) 4 = 100 ips upstream (NDP250-NDP600)5-255 = Reserved for future transports Image Quality Defines the QualityFlags that have been Enabled Flags enabled by the imaging institution.See “Image Quality Flags Enabled” bit patterns defined below fordetails. Minimum CCITT Set the “Below Minimum Image Size” CompressedQuality Flag if the flag is enabled and if Packet Size the CCITT imagepacket size is less than or equal to this value (in 100-byte units).Maximum CCITT Set the “Exceeds Maximum Image Size” Compressed QualityFlag if the flag is enabled and Packet Size if the CCITT image packetsize is greater than or equal to this value (in 100-byte units). MinimumAux CCITT Set the “Below Minimum Image Size” Compressed Quality Flag ifthe flag is enabled and Packet Size if the Auxiliary CCITT image packetsize is less than or equal to this value (in 100-byte units). Fortransports fitted with Dual Filter cameras. Maximum Aux CCITT Set the“Exceeds Maximum Image Size” Compressed Quality Flag if the flag isenabled and Packet Size if the Auxiliary CCITT image packet size isgreater than or equal to this value (in 100-byte units). For transportsfitted with Dual Filter cameras. Minimum JPEG Set the “Below MinimumImage Size” Compressed Quality Flag if the flag is enabled and PacketSize if the JPEG image packet size is less than or equal to this value(in 100-byte units). Maximum JPEG Set the “Exceeds Maximum Image Size”Compressed Quality Flag if the flag is enabled and Packet Size if theJPEG image packet size is greater than or equal to this value (in100-byte units). Minimum Aux JPEG Set the “Below Minimum Image Size”Compressed Quality Flag if the flag is enabled and Packet Size if theAuxiliary JPEG image packet size is less than or equal to this value (in100-byte units). For transports fitted with Dual Filter cameras. MaximumAux JPEG Set the “Exceeds Maximum Image Size” Compressed Quality Flag ifthe flag is enabled and Packet Size if the Auxiliary JPEG image packetsize is greater than or equal to this value (in 100-byte units). Fortransports fitted with Dual Filter cameras. Minimum Set the “BelowMinimum Document Document Height Height” Quality Flag if the compressordetects a document height lower than or equal to this value (in 1/10inch units). Maximum Set the “Exceeds Maximum Document Document HeightHeight” Quality Flag if the flag is enabled and if the compressordetects a document height greater than or equal to this value (in 1/10inch units). Minimum Set the “Below Minimum Document Document LengthLength” Quality Flag if the flag is enabled and if the compressordetects a document length lower than or equal to this value (in 1/10inch units). Maximum Set the “Exceeds Maximum Document Document LengthLength” Quality Flag if the flag is enabled and if the compressordetects a document length greater than or equal to this value (in 1/10inch units). Reserved Reserved for future expansion

IQF_Record_Structure (512 bytes) Name Description IDX Offset Offset ofthis document in IDX file Global Image Quality Bit pattern indicatingthe image renditions that Conditions have reported image qualityconditions. See the “Global Image Quality Conditions” definition below.Front 1 Image Quality Image quality conditions specific to the 1^(st)“front Conditions image” rendition of the document. See the “ImageQuality Conditions” definition below. Rear 1 Image Quality Image qualityconditions specific to the 1^(st) “rear Conditions image” rendition ofthe document. See the “Image Quality Conditions” definition below. Front2 Image Quality Image quality conditions specific to the 2^(nd) “frontConditions image” rendition of the document. See the “Image QualityConditions” definition below. Rear 2 Image Quality Image qualityconditions specific to the 2^(nd) “rear Conditions image” rendition ofthe document. See the “Image Quality Conditions” definition below.Reserved Reserved for future expansion.

Image_Quality_Conditions (33) bytes for each image redention) NameDescription Global Image An ASCII code that indicates whether theQuality image rendition was tested for any of the conditions related toX9.37 image quality definitions. ‘0’ - The image was not tested for anyof the image quality conditions. ‘1’ - The image was tested and one ormore image quality conditions were reported. ‘2’ - The image was testedand no image quality conditions were reported. Partial An ASCII codethat indicates if only Image a portion of the image rendition isrepresented digitally while the other portion is suspected to be missingor corrupt. ‘0’ - Test not done. ‘1’ - Condition present. ‘2’ -Condition not present Excessive An ASCII code that indicates if theImage Skew image skew exceeds an acceptable value. This value isspecific to the imaging institution's own defined requirements and/orconstraints. ‘0’ - Test not done. ‘1’ - Condition present. ‘2’ -Condition not present Piggyback An ASCII code that indicates if a Image“piggyback” condition has been detected. With a “piggyback condition,the intended image may be extended, obscured, or replaced by image(s) ofadditional document(s). A piggyback occurs when two or more documentsare fed together and captured as one document when only a singledocument should have been fed and captured. ‘0’ - Test not done. ‘1’ -Condition present. ‘2’ - Condition not present Too Light Or An ASCIIcode that indicates if the Too Dark image is too light or too dark. Thevalue is specific to the imaging institution's own defined requirementsand/or constraints. ‘0’ - Test not done. ‘1’ - Condition present. ‘2’ -Condition not present Streaks And Or An ASCII code that indicates if theBands image is likely corrupted due to streaks and/or bands. Streaks andbands can be caused by such problems as dirt, dust, ink, or debris on alens or in the optical path. ‘0’ - Test not done. ‘1’ - Conditionpresent. ‘2’ - Condition not present Below Minimum An ASCII code thatindicates if the Image Size size of the compressed image is below anacceptable value. The value is specific to the imaging institution's owndefined requirements and/or constraints, and is defined by the ”MinimumCompressed Packet Size” Image Quality Threshold for this imagerendition. ‘0’ - Test not done. ‘1’ - Condition present. ‘2’ - Conditionnot present Exceeds Maximum An ASCII code that indicates if the ImageSize size of the compressed image is above an acceptable value. Thevalue is specific to the imaging institution's own defined requirementsand/or constraints, and is defined by the ”Maximum Compressed PacketSize” Image Quality Threshold for this image rendition. ‘0’ - Test notdone. ‘1’ - Condition present. ‘2’ - Condition not present ReservedReserved for emerging image quality technologies. Reserved Reserved foremerging image quality technologies. Reserved Reserved for emergingimage quality technologies. Reserved Reserved for emerging image qualitytechnologies. Reserved Reserved for emerging image quality technologies.Reserved Reserved for emerging image quality technologies. ReservedReserved for emerging image quality technologies. Reserved Reserved foremerging image quality technologies. Reserved Reserved for emergingimage quality technologies. Reserved Reserved for emerging image qualitytechnologies. Reserved Reserved for emerging image quality technologies.Reserved Reserved for emerging image quality technologies. ReservedReserved for emerging image quality technologies. Image Quality Seedefinitions for “Image Quality Bit Fields Bit Fields” below.

Image_Quality_Bit_Fields (96 bits for each image rendition) BitDescription Bit 0: Partial 0 = Entire image is present, or condition notImage Flag tested. 1 = Portion of the image is suspected to be missing.Bit 1: Excessive 0 = Image skew does not exceed an Document Skewacceptable value, or condition not tested. Flag 1 = Image skew exceedsan acceptable value. Bit 2: Piggyback 0 = Piggyback condition notpresent, or not Image Flag tested. 1 = Piggyback condition present. Bit3: Too Light 0 = Too Light or Too Dark condition not present, or TooDark or not tested. Flag 1 = Too Light or Too Dark condition present.Bit 4: Streaks 0 = Streaks and/or bands not detected, or not and/orBands tested. Flag 1 = Streaks and/or bands detected.. Bit 5: Below 0 =The compressed image is not below an Minimum acceptable value, orcondition not tested. Image Size 1 = The compressed image is below anFlag acceptable value. Bit 6: Exceeds 0 = The compressed image is notabove Maximum an acceptable value, or condition not tested. Image Size 1= The compressed image is above an Flag acceptable value. Bits 7-19 0 =Reserved Bit 20: Feed- 0 = “Feed-check” condition not check detected, orcondition not tested. 1 = “Feed-check” condition detected. Bit 21: BOL 0= “BOL Late” condition not Late detected, or condition not tested. 1 =“BOL Late” condition has been detected. Bit 22: Framing 0 = “FramingError” condition not Error detected, or condition not tested. 1 =“Framing Error” condition has been detected. Bit 23: Below 0 = Adocument height greater than the Minimum “Minimum Document Height” hasbeen Document detected, or condition not tested. Height 1 = A documentheight lower than or equal to the “Minimum Document Height” ImageQuality Threshold has been detected. Bit 24: Exceeds 0 = A documentheight lower than the Maximum “Maximum Document Height” has beenDocument detected, or condition not tested. Height 1 = A document heightgreater than or equal to the “Maximum Document Height” Image QualityThreshold has been detected. Bit 25: Below 0 = A document length greaterthan the Minimum “Minimum Document Length” has been Document detected,or condition not tested. Length 1 = A document length lower than orequal to the “Minimum Document Length” Image Quality Threshold has beendetected. Bit 26: Exceeds 0 = A document length lower than the Maximum“Maximum Document Length” has been Document detected, or condition nottested. Length 1 = A document length greater than or equal to the“Maximum Document Length” Image Quality Threshold has been detected.Bits 27-95 0 = Reserved.

1. A document processing system comprising a document transport formoving a plurality of documents and at least one computer running systemsoftware that interfaces with the document transport to provide documentcontrol, the document processing system further comprising: an imagecapture subsystem connected to the document transport for capturingselected image metrics and at least one image rendition from theplurality of documents as they are moved by the document transport, theimage capture subsystem determining if at least one of the selectedimage metrics for any of the at least one image rendition does notsuccessfully compare against preselected image quality metric thresholdvalues, generating an image quality flag for any of the at least oneimage rendition if it does not successfully compare, and creating in animage quality flag file, a record entry for each imaged document havingat least one flagged image rendition, each record entry includinginformation about the at least one flagged image rendition for thatimaged document, whereby image defects in the plurality of documents canbe identified by examining the record entries in the image quality flagfile; wherein the image capture subsystem further creates an image indexfile that, for each document, provides pointers to associated images andincludes a global image quality flag for indicating image quality testresults for the document and an image quality record index field thatpoints to the associated record entry, if any, in the image quality flagfile; and wherein each record entry in the image quality flag filefurther includes a cross-reference to the corresponding part of theimage index file for the document corresponding to that particularrecord entry.
 2. The document processing system of claim 1, wherein theimage capture subsystem comprises: imaging module hardware for capturingimages; and, an image capture server for processing and storing thecaptured images.
 3. The document processing system of claim 1, furthercomprising track hardware, wherein the track hardware provides selecteddocument metrics from a plurality of documents as they are moved by thedocument transport, and further wherein the image capture subsystemdetermines if at least one of the selected document metrics for any ofthe documents does not successfully compare against preselected documentmetric threshold values, generates an image quality flag for any of thedocuments if it does not successfully compare, and creates in the imagequality flag file, a record entry for each imaged document having atleast one flagged document metric, wherein each record entry includesinformation about the at least one flagged document metric for thatimaged document.
 4. The document processing system of claim 2, whereinthe image capture server: analyzes each of the at least one imagerendition of each imaged document in an image quality metric generationprocess to provide selected image metrics; compares the selected imagemetrics for each of the at least one image rendition of each imageddocument against preselected image quality metric threshold values;generates an image quality flag for any of the at least one imagerendition of the plurality of imaged documents if at least one of theselected image metrics for that image rendition does not successfullycompare against the preselected image quality metric threshold values;and, creates a record entry in an image quality flag file for each ofthe plurality of imaged documents having at least one flagged imagerendition, the record entry including information about the selectedimage metrics of the at least one flagged image rendition for thatimaged document, wherein the image defects in a plurality of imageddocuments can be identified by examining the record entries in the imagequality flag file.
 5. The document processing system of claim 1, furthercomprising: captured image storage means for storing according to typeof image rendition, the at least one image rendition captured by theimage capture subsystem for each of the plurality of documents; imagequality flag file storage storing the image quality flag file; and,image index file storage means for storing the image index file.
 6. Thedocument processing system of claim 5, wherein the captured imagestorage means includes first front image rendition storage.
 7. Thedocument processing system of claim 6, wherein the captured imagestorage means further includes first rear image rendition storage. 8.The document processing system of claim 7, wherein the captured imagestorage means further includes second front image rendition storage. 9.The document processing system of claim 8, wherein the captured imagestorage means further includes second rear image rendition storage. 10.The document processing system of claim 5, further comprising an imagingapplication executing in the image capture subsystem, wherein for eachof the plurality of imaged documents, the method further comprising thestep of: setting the global image quality flag for an image index filerecord, the record corresponding to an imaged document, in the imageindex file, the global image quality flag indicating that thecorresponding imaged document has been checked for image defects.
 11. Adocument processing system comprising: transport means for physicallyprocessing a plurality of documents; track control means for controllingthe transport means; and, image capture subsystem means, includingimaging module hardware for capturing selected image metrics and aplurality of image renditions from documents as they are moved by thedocument transport; an image capture server for receiving the capturedselected image metrics and plurality of image renditions from theimaging module hardware, the image capture server including softwarerunning thereon, the software adapted to determine if at least one ofthe selected image metrics for any of the image renditions does notsuccessfully compare against preselected image quality metric thresholdvalues, to generate an image quality flag for any of the imagerenditions if it does not successfully compare, and to create an imagequality flag file that contains a record entry for each imaged documenthaving at least one flagged image rendition, wherein each record entryincludes the at least one flagged image rendition for that imageddocument; wherein the image capture software creates an image index filethat, for each document, provides pointers to associated images andincludes a global image quality flag for indicating image quality testresults for the document and an image quality record index field thatpoints to the associated record entry, if any, in the image quality flagfile; and wherein each record entry in the image quality flag filefurther includes a cross-reference to the corresponding part of theimage index file for the document corresponding to that particularrecord entry.
 12. The document processing system of claim 11, whereinthe transport means provides selected document metrics from a pluralityof documents, and further wherein the image capture subsystem determinesif at least one of the selected document metrics for any of thedocuments does not successfully compare against preselected documentmetric threshold values, generates an image quality flag for any of thedocuments if it does not successfully compare, and creates in the imagequality flag file, a record entry for each imaged document having atleast one flagged document metric, wherein each record entry includesinformation about the at least one flagged document metric for thatimaged document.
 13. The document processing system of claim 12, whereinthe selected document metrics are selected from the group comprisinginformation about the type and information about the physical dimensionsof each of the plurality of imaged documents.
 14. The documentprocessing system of claim 13, wherein the selected document metricsinclude a beam-of-light (BOL) “late” signal.
 15. The document processingsystem of claim 14, wherein the selected document metrics include adocument spacing error signal.
 16. The document processing system ofclaim 15, wherein the selected document metrics include a doubledocument signal.
 17. The document processing system of claim 12, furthercomprising: captured image storage for storing according to type ofimage rendition, the image renditions captured by the image modulehardware for each of the plurality of documents; image quality flag filestorage for storing the image quality flag file; and, image index filestorage for storing the image index file.